Machine-to-Machine (M2M) communications (in some cases referred to as Machine-Type Communications MTC) is a designation to describe communications and technologies that permit both wireless and wired communications devices (MTC device) to communicate directly or across a network (such as an Internet Protocol (IP) network) with other devices or with applications running on remote servers.
Those having ordinary skill in the relevant art will appreciate that for the most part, the acronyms “M2M” and “MTC” may be used interchangeably. Nevertheless, applications relating to such communications and technologies are typically referred to as “M2M applications”, while traffic is typically referred to as “MTC traffic”. Devices may typically be referred to as “M2M devices” or “MTC devices”. Additionally, certain standards bodies may tend to refer to one term in preference to the other.
MTC may be differentiated from Human-Type Communications (HTC) such as voice and data communications using smartphones, laptops or tablets, in that MTC traffic may be generally characterized as being sporadic and low bandwidth, while HTC traffic may be characterized as involving a substantially incessant demand for high bandwidth. Thus, as noted in 3GPP TS 23.888, “System improvements for Machine-Type Communications (MTC)”, <http://www.3gpp.org/ftp/Specs/html-info/23888.htm> and IETF RFC 7252, “The Constrained Application Protocol (CoAP)”, June 2014, <http://tools.ietf.org/html/rfc7252>, MTC traffic may typically involve the exchange of a few small packets in very short-lived (relative to HTC communications) packet flows.
The term “packet flow” may, in some example embodiments, refer to “a unidirectional sequence of packets with some common properties that pass through a network device”, as defined in IETF RFC 3954, “NetFlow Services Export” , October 2004, <http://tools.ietf.org/html/rfc3954>.
In some cases the packet flow may consist of a single packet, typically in the uplink (UL) direction (from the MTC device to a remote corresponding node (RCN) recipient). Further, the period between packet bursts (relative to HTC communications) may be quite long, ranging from minutes to hours.
Moreover, MTC communications systems may be differentiated from HTC systems in that it is anticipated, and taken into account in network design, that there will be a very large number of MTC devices (relative to HTC devices) within a network coverage area.
In general, the term “wireless device” may encompass both MTC devices and HTC devices, and other untethered communications devices, including without limitation, User Equipment (UE), Fixed Stations (FS) and Mobile Stations (MS).
As a non-limiting example, an MTC device such as a sensor or meter may be configured to capture an event, such as a temperature, a sensor reading or an inventory level, and relay it (in the UL direction) through a network to an M2M Application somewhere in the Internet-at-large, that compiles (for example in conjunction with one or more events captured by the same, or one or more additional, MTC device(s), or one or more other data sources) information and analyzes such information to perform one or more actions. In some cases, such action may include providing one or more requests to the MTC device (in the downlink (DL) direction).
A schematic view of an example configuration of certain functional elements of a MTC wireless network is described in FIG. 1 as may be used, for example, in a Third Generation Partnership Project (3GPP) network. The network, shown generally at 100, comprises at least one Remote Corresponding Node, such as an Application Server (AS) 110, at least one Border Gateway (BG) 115, at least one MTC Inter-Working Function (MTC-IWF) 120, at least one Radio Access Network (RAN) 130 and at least one MTC device 140 and the Internet-at-large, shown as 150.
The RCN 110 is coupled through the Internet-at-large 150 to the BG 115 and comprises at least one M2M Application 111. The M2M Application 111 may comprise application-specific logic for managing, configuring, controlling and communicating with one or more of the MTC devices 140. In general, the term “Remote Corresponding Node” encompasses application servers (AS), wired and wireless end node devices, and other network nodes communicatively coupled to the RAN 130.
The Internet-at-large 150 couples the RCN 110 to the RAN 130 and MTC-IWF 120 through the BG 115.
The BG 115 couples the MTC-IWF 120 and the RAN 130 to the Internet-at-large 150. The BG 115 manages communication through the Internet-at-large 150 to the RCN 110.
The MTC-IWF 120 is coupled to the RCN 110 through the BG 115 and the Internet-at-large 150 and to the RAN 130.
The RAN 130 is coupled to the MTC-IWF 120 and BG 115 and is coupled to at least one MTC device 140. The RAN 130 may comprise at least one access point (AP) 131. The AP 131 manages communications over a radio link 160 to the MTC device 140. In general, the term “Access Point” encompasses Base Stations (BS), base station controllers, radio network controllers, Node-Bs, evolved Node-Bs (eNBs) and other radio access controllers. It may also encompass network nodes such as access routers that may be responsible for packet flow management.
The MTC device 140 is wirelessly coupled to at least one of the APs 131 comprising the RAN 130. The MTC device 140 may comprise one or more MTC client applications that communicates with a corresponding M2M application 111. The MTC device 140 may be a stand-alone device or may comprise an element of a wireless device (WD).
M2M communications are typically dominated by UL (away from the MTC device 140) traffic sent by the MTC client application to the corresponding M2M application 111 to report an event. Occasionally, the M2M application will transmit a DL (toward the MTC device 140) packet to the MTC device 140, for example to update a configuration of the MTC device 140, or to request a report of information to the M2M application 111.
As such, given the relatively low frequency of UL communications and even lower frequency of DL communications, the MTC device 140 may be configured to enter a low-power battery state and avoid all communications with the M2M Application 111 along the wireless network or RAN 130 in order to conserve battery power. This does not typically pose any issue with regard to UL communication of events, since such events generally originate with the MTC device 140, and the MTC device 140 can resume a higher-power battery and operational state before generating (and in some cases capturing) the event and communicating it in an UL packet to the M2M Application 111.
However, DL communications may occur infrequently and without warning. To this end, a number of mechanisms have been developed to permit the MTC device 140 to re-enter a higher-power battery state sufficient to receive DL communications from the M2M Application 111.
For example, the MTC device 140 may be alerted to the arrival of a DL packet from time to time by the RAN 130, including through a paging mechanism. In such a case, as described in 3GPP TS 36.331, “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Radio Resource Control (RRC) protocol specification”, <http://www.3gpp.org/ftp/Specs/html-info-36331.htm>, the MTC device 140 is configured to listen for an alert during predefined paging opportunities (which may include one or more specific points in time and/or one or more specific sets of radio resources). When the MTC device 140 detects a page during one of such paging opportunities, it obtains radio resources to receive one or more DL packet(s) from the M2M Application 111, which may have been previously buffered by the RAN 130 for DL transmission to the MTC device 140. If no page is detected during a paging opportunity, the MTC device 140 may return to a low battery state until the next scheduled paging opportunity.
In another example, as described in 3GPP TS 36.331, “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Radio Resource Control (RRC) protocol specification”, <http://www.3gpp.org/ftp/Specs/html-info-36331.htm>, a semi-persistent schedule may be employed in which the MTC device 140 is scheduled to listen for DL transmissions on specific radio resources at specific times. In such example, the RAN 130 can transmit DL packets to the MTC device 140 without any initial alerting or paging sequence.
Unicast packet forwarding in the Internet is designed to deliver a packet from a source node to a fixed point in the network where the destination node is (currently) attached. The network IP address used as a destination address in a packet header identifies this point of attachment. Thus, as with wireless devices in general, in order to identify an MTC device 140 and allow it to be differentiated from other wireless devices, the device is assigned a semi-static IP address. In today's mobile wireless environment, an IP address is normally assigned to (an interface on) a wireless device when the wireless device registers with the network. Currently, the IP address may be assigned using one of at least four mechanisms.
The first mechanism involves (typically manual) configuration of an IP address into each wireless device during the manufacturing process. In so doing, the deployment of such device may be constrained to a geographical (or otherwise) area where its assigned IP address maps onto a corresponding subnet. As a result, higher inventory costs may be incurred due to stockpiling of replacements on a per-subnet basis rather than for a general population of wireless devices.
The second mechanism involves manual pre-provisioning of an IP address into each wireless device before deployment. Such mechanism increases the labour and associated costs of deployment of the device. Furthermore, considerable effort is expended in managing the pool of available IP addresses. Nevertheless, despite such efforts, deployed devices may sometimes be replaced without invoking proper address recycling procedures. As a result, over time, otherwise valid IP address may be “lost”.
The third mechanism involves use of a protocol such as the Dynamic Host Configuration Protocol (DHCP) to dynamically assign an IP address to the wireless device. DHCP involves both a client in the wireless device as well as network infrastructure to support the protocol. These demands increase the cost and complexity of both the wireless device and the supporting network architecture.
The fourth mechanism involves use of a method such as (IPv6) StateLess Address Auto-Configuration (SLAAC) to dynamically assign an IP address to the wireless device. As with DHCP, SLAAC involves both a client in the wireless device as well as network infrastructure, which increases the cost and complexity of both the wireless device and the supporting network architecture. Further, SLAAC calls for the periodic broadcast of router advertisement messages by the network to announce the available subnet prefix, which consumes radio link bandwidth and resources.
Thus, depending upon the mechanism employed, the assignment of an IP address to an MTC device 140 may either increase the complexity and cost of the MTC device 140, or may incur significant deployment costs with each MTC device 140 as well as increase overhead costs. Given the current and rapidly increasing number of MTC devices 140, such complexity and costs can become very large, to the extent that it may begin to impact the cost-effectiveness of employing MTC technology.
Moreover, it is expected that as MTC devices 140 become more pervasive, network topologies may increasingly be characterized by heterogenous networks (HetNets) having a large number of small cells serving a dense population of mobile, mostly MTC devices 140. Typically, a wireless device retains its assigned IP address for as long as it is active within the RAN 130. In contrast to operations in the Internet-at-large, the assigned IP address identifies a Mobility Anchor (MA) point (not shown) rather than where the wireless device is (currently) attached to the RAN 130. However, whenever a wireless device changes its point of attachment at the radio edge, control plane signalling packets are exchanged between a serving AP 131 and the MA (not shown) for the wireless device. Thus, it is expected that control signalling overheads will begin to escalate.
As discussed above, typically, an MTC device 140 may enter a low-power state and avoid all communications with the RAN 130 between UL packet bursts of event information. It is conceivable that a mobile MTC device 140 could change its point of attachment while in a low-power state. If so, the RAN 130 would be expected to redirect DL traffic to the new point of attachment. Currently, there are at least two approaches that could be appropriated to do so.
First, tunnelling solutions, including General Packet Radio System (GPRS) Tunnelling Protocol (GTP) disclosed in 3GPP TS 29.281, “General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)”, <http://www.3gpp.org/ftp/Specs/html-info/29281.htm>, Mobile IP (MIP) disclosed in IETF RFC 6275, “Mobility Support in IPv6”, July 2011, <http://tools.ietf.org/html/rfc6275>, and their derivatives, may be employed to provide encapsulation of a client packet inside a tunnel packet by the MA for flows addressed to a particular device or device interface. The destination address in the tunnel packet identifies the point of attachment, such as an AP 131, and the destination address in the original (encapsulated) packet identifies the actual destination wireless device. This increases the size of each packet, leading to a concomitant increase in bandwidth demand. In some cases, in which backhaul links, such as wireless backhaul and mesh links, are bandwidth-constrained, such increase in demand may be particularly acute. Moreover, the increased size of the packets because of the encapsulating tunnel packets, may lead to an increased frequency of fragmentation and reassembly of the oversized packet, resulting in even greater bandwidth and processing overheads. Some variants support forwarding for individual flows but these incur a commensurate increase in the number of “care-of” addresses that are allocated, and in the amount of context information that is maintained by the ingress routers.
Second, a new IP address may be assigned when the mobile MTC device 140 changes its point of attachment. This may incur considerable signalling overhead when using, by way of non-limiting example, DHCP or SLAAC. Given that many MTC devices 140 are portable and rely on battery power, such overhead can have an impact on battery life and thus on the operational life of the MTC device 140.
Furthermore, every wireless device has an associated RAN context. Such context is typically comprised of information related to resources assigned to the device by the RAN 130. Such information may include any or all of UL and/or DL transmission schedules, Quality of Service (QoS) requirements and transmission parameters.
The issue becomes more acute having regard to the sporadic nature of typical MTC device 140 communications. While the MTC device 140 is in a low-power state between UL packet bursts, the RAN 130 decides between two options.
The first option is for the RAN 130 to maintain the context information for the MTC device 140. While this minimizes processing, both in the RAN 130 and the MTC device 140 itself, when the MTC device 140 resumes communications, the maintained context information will occupy storage in the RAN 130. Thus, the resources that will be allocated in the RAN 130 for storage and maintenance of such context information may grow very large when the expected massive number of MTC devices 140 is deployed for service by the RAN 130.
The second option is to discard the context information for the MTC device 140 when it enters the low-power state and to generate new context information when the MTC device 140 resumes communications. While alleviating demands on RAN 130 storage, this option increases the communications and processing load on the RAN 130 and on the MTC device 140. Again, given that many MTC devices 140 are portable and rely on battery power, such load can have an impact on battery life and thus on the useful operational life of the MTC device 140. Moreover, the increased communications and processing load may incur delays in resuming communications between the M2M application 111 and the MTC device 140.
Therefore there exists a need to reduce the overheads associated with maintaining context for large numbers of MTC devices and for forwarding packets to MTC devices in a mobile environment while, at the same time, reducing the amount of battery power consumed in an MTC device, reducing the amount of signalling between an MTC device and a RAN and any combination of any of these.
In the present disclosure, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the present disclosure. In some instances, detailed descriptions of well-known devices, circuits and methods are omitted so as not to obscure the description of the present disclosure with unnecessary detail.
Accordingly, the system and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present disclosure, so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
Any feature or action shown in dashed outline may in some example embodiments be considered as optional.